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Abstract —The Hypertext Transfer Protocol (HTTP), a key 
building block of the World Wide Web, has succeeded to enable 
information exchange worldwide. Since its first version in 1996, 
HTTP/1.0, the average number of inlined objects and average 
total bytes per webpage have been increasing significantly for 
desktops and mobiles, from 1-10 objects in 1996 to more than 100 
objects in June 2014. Even if the retrieving of inlined objects can 
be parallelized as a given Hypertext Markup Language (HTML) 
document is streamed, a maximum number of connections is 
allocated, and thus as the number of inlined objects increases, 
the overall webpage load duration grows, and the HTTP servers 
loading also gets higher. To overcome this issue, we propose a 
new HTTP method called BURST, which allows to retrieve the 
missing inlined objects of a webpage efficiently by requesting 
sets of web objects. We experimentally demonstrate the potential 
via a proof-of-concept demonstration, by comparing the regular 
HTTP to proposed HTTP-Burst using a virtual private server 
and real HTTP client and server over the Internet. The results 
indicate a latency reduction of webpage load duration compared 
to HTTP as high as 52 % under the considered configurations. 

1. Introduction 

The Hypertext Transfer Protocol (HTTP) Q, which first 
version was established in 1996, is a key building block proto¬ 
col in the Internet. HTTP works on a request-responce manner, 
where the GET, POST, PUT, and DELETE are the most 
commonly used methods. The most frequent method from 
an end-user standpoint is the GET method, which retrieves a 
web document from an HTTP server. A typical document type 
is the HyperText Markup Language (HTML), which contains 
HTML elements as well as reference to external objects, the 
so-called inlined objects. Each of those inlined objects are 
retrieved via successive GET requests, typically in parallel as 
the HTML document is obtained. 

Several different optimization techniques have been pro¬ 
posed to improve the HTTP performance, from the client, 
network, and server viewpoints in order to minimize the 
request latency. To avoid fetching two times the same exact 
document, the end-user can store locally the document, which 
is possible by using a local cache. Proxy web caches are also 
widely used, where an intermediate node between the clients 
and server stores frequently used documents (2)-i4|. Caching 
can also be done on the server side mainly to decrease 
the request computation duration especially when complex 
calculations or database queries are executed. Web caching 
on the server side is frequently done by saving content in 
memory for fast lookup A typical performance metric used 
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Pig. 1: Evolution of the average page size and number of 
objects from 1995 to 2014 | [T0| . 


in web caching is the hit rate, which corresponds to the ratio 
of the number of requests using the cache over the number of 
requests. 

Other improvement techniques focused on the exchanged 
HTTP messages. Por instance, the HTTP data can be com¬ 
pressed to reduce the transmitted bytes Q. Purther, it is worth 
noting that HTTP works by maintaining Transmission Control 
Protocol (TCP) connections. HTTP 1.1, as opposed to HTTP 
1.0, introduced the persistent connections (HTTP Keep-alive), 
allowing to make multiple HTTP requests/responses over the 
lifetime of a given connection. This mechanism significantly 
reduces the overhead, as verified in It thus improves the 
transport layer communications for the HTTP traffic. 

All of these techniques improve the request-response la¬ 
tency. It is worth nothing that the HTTP request-response 
latency performance highly depends on the number of inlined 
objects (e.g., images, fonts, etc.) to retrieve j^. Since 1995 
up to now, the number of inlined objects per webpage has 
significantly increased, as depicted in Pig. from few 

objects to more than 100 objects in 2014. In the authors 
measured this issue in the early HTTP version and proposed 
new methods, GETALL and GETLIST. GETALL, as opposed 
to the GET method, requests to retrieve a given document and 
its inlined objects for improved efficiency. 

In this paper, we propose the BURST method, which is 
somewhat a variant of the GETALL method proposed in 0- 
However, rather than requesting the document and all inlined 
objects, the proposed extension first requests the document and 
then the missing inlined objects, and it allows to have multiple 
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BURST requests to be sent in parallel to decrease latency. 

This paper is structured as follows. In Section [I^ we 
overview the HTTP traffic trends to motivate the proposed 
method. In Section ITO we describe the overall HTTP protocol 
and propose an extension in Section In Section [V| we 
investigate experimentally the proposed method and compare 
it to the regular HTTP protocol. Section [V^ finally draws some 
conclusions. 


H. HTTP Traffic Trends 

In this section, we overview the trends of the traffic gener¬ 
ated by HTTP-based web applications. In 1996, httparchive. 
org was founded, aiming at keeping snapshots of the websites 
evolution by archiving the different versions of webpages over 
time. More interestingly for the scope of this paper, statistics 
can be generated of the HTTP-based Internet traffic (TT) We 
are interested to look at the traffic, in average, generated by a 
webpage. Fig. [^depicts the total average size in June 2015 of 
an accessed webpage, namely 2.1 MB (Fig.[^) from desktops 
and 1.18 MB (Fig. [2b|)) from mobile devices. Note that it does 
not take into account the scenario of a webpage where a given 
client has cached objects from previous requests, but illustrates 
the scenario where a user first access a given website/webpage 
without saved objects. Further, Fig. illustrates the average 
data size for the main downloaded object types while loading 
a page. 



total 2131 kB 



total 1180 kB 
(b) Mobile. 


Fig. 2: HTTP average object size per content type (June 2015) 



If we look more specifically on the webpages generated for 
desktops (Fig. |^), the two average largest content type sizes 
are originating from images and scripts (e.g.. Javascript files). 
On the mobile counterpart (Fig.|^), the average content sizes 
are reduced, mainly according to the images, scripts, and fonts 
sizes. 
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Fig. 3: Average page size and number of objects from 2010 
to 2015 0. 


One could however wonder how did the total webpage 
size has evolved since 1995 and beyond. In Fig. one can 
observe that the average webpage size has been growing since 
1995 until now, and will more likely continue to grow given 
this trend. More specifically, the average webpage size has 
been growing significant since 2010, perhaps related to the 
economic growth that followed the economic crisis of 2008. 

It is worth noting that an HTTP page load, which we will 
briefiy overwiew in the next section, basically consists of an 
HTML document request, followed by successive object file 
requests for images, scripts, etc. Fig. depicts the averages 
total number of requests and total bytes a webpage is creating. 
Approximately 75 % of webpage loads require between 1 and 
125 HTTP requests, which is quite significant, given that each 
given HTTP request further generates overhead from the IP 
and TCP layers, as well as increasing server loading. 
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(a) HTTP requests per page. 



(b) Transmitted MB per page (including all objects). 

Fig. 4: HTTP requests and transmitted KB per page (June 
2015) 1^. 

If we look in Fig. at the content type generating the 
largest amount of traffic, the images, we observe that 85 % of 
webpages contain between 1 and 80 images. 

If we multiply the ratios to the number of requests in Fig. 
[4a| ), approximately 91 requests are generated per webpage 
load. In the following, we overview HTTP to outline the 
consequence of having such a growing amount of requests. 
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(a) Images per page. 
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(b) Images size per page (including all images). 


Fig. 5: Number and total size of images per page (June 2015) 



HTTP client HTTP server 



Fig. 6: HTTP example execution of one HTML file containing 
four images using the GET method (C = 2). 


HI. Hypertext Transeer Protocol (HTTP) 

The Hypertext Transfer Protocol (HTTP) is an application 
protocol for distributed and collaborative information systems, 
which is one of the most widely used protocol in the Internet 
Q. HTTP has a variety of request methods, including GET, 
HEAD, POST, and DELETE. The GET method is the most 
widely used method, which role is to retrieve a specified 
resource, while the POST method is used to for instance in 
web forms to submit data entities. Pig. [^depicts an HTTP GET 
example of a script request (file.php) containing four images. 
In the example, a maximum of two files can be transferred 
in parallel. Note that the number of parallel connections vary 
depending on the web browser, from 6 in Chrome and Pirefox 
up to 13 in Internet Explorer 11 Q Por each given request, 
TCP acknowledgement (ACK) packets are generated for con¬ 
firmation. Therefore, as the number of objects in requested 
webpages increases, the experienced overhead grows. 


Por instance, the IPv4 and TCP headers correspond to 20 bytes 
each. IP^TCP^HTTP is counted twice due to the request 
and response messages. Note that, on the top of this, the link 
layer (e.g., Ethernet) also adds extra overhead which we do 
not take into account for improved readability. Therefore, the 
maximum efficiency is given by: 


E 

E 


N 

i=l 

N 

i=l 



( 2 ) 


Thus, as the number of objects increases, the overhead 
data size increases. Por instance, if the average object size 
corresponds to 200 bytes with N = 3, then the maximum 
efficiency is 3 . 2 o^o+ 3 °i 20 = 62-5 %. 


B. Delay 

In terms of delay, the number of objects has a major impact 
on the webpage load time, which corresponds to: 


A. Maximum Efficiency 

As we illustrated in the previous section, the number of 
objects per webpage is significantly increasing over time since 
1995. Let us consider N objects (scripts, images, videos, etc.) 
included in a given webpage. Each object size i corresponds 
to Li (in bytes) such that i G An HTTP request 

for a given object i thus totals the following minimum amount 
of bytes: 

Ri = 2 • {IP P TCP P HTTP) P ACK P Li, (1) 

where IP and TCP corresponds to the Internet Protocol 
(IP) and Transmission Control Protocol (TCP) header sizes, 
HTTP the size of the HTTP request excluding the payload 
of Li bytes, and ACK = IPpTCP corresponds to the TCP 
ACK packet generated from the HTTP server to a given client. 

^Browserscope web browsers profiling: http://www.browserscope.org/ 
?category=network 


N 

Dmax — ^ + D (^) 

i=l 

where and Dl^c correspond to the delay between 

the client and server, and inversely, pi^g corresponds to the 
processing delay at the server to process object i. Note that 
this delay is correct if a single connection is used, which is 
usually not the case. If the browser uses C connections, then 
the delay D corresponds to: 

n = (A\ 

C ' ^ 

It is clear that the webpage load time D grows as the number 
of objects N increases. To overcome this shortcoming, we 
propose HTTP-Burst in the following section. 

IV. HTTP-Burst 

Por improved efficiency, we propose to transfer all missing 
objects, not stored in a local cache, in a single request 
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HTTP client 


HTTP server 


[Initialization] 
GET file.php 


ACK 

BURSTimgn-4j.jpg 



ACK 

200 OK, (file.php) 


ACK 

(inng[1-4].jpg) 


Fig. 7: HTTP-Burst example execution of one HTML file 
containing four images using the BURST method (C = 1). 


HTTP client 


HTTP server 



ACK 

200 OK, (file.php) 


ACK 

(img[1-2j.jpg) 
ACK 

(imgP-4j.jpg) 


Fig. 8: HTTP-Burst example execution of one HTML file 
containing four images using the BURST method (C = 2). 



Number of objects 


Fig. 9: Maximum efficiency, = 1400, VL 


B. Delay 

In terms of delay, it is definitely improved since few two- 
way communications exchanges are done: 

D = maxDl^^ + (6) 

where c is the BURST connection identifier, i = 1,2,...,C. 

Further, as the number of requests is reduced, processing 
only C HTTP request instead of N definitely reduces the server 
load. 


as a burst using a new BURST method, as illustrated in 
Fig 0 In such a scheme, when the GET method has been 
completed and the HTTP client has completely received the 
HTML content, one or many BURST requests are sent each 
containing a set of objects to retrieve from the HTTP server, 
for example to retrieve four images, imgl.jpg, ..., img4.jpg 
with a single connection (C = 1) as in Fig|7] Then, the HTTP 
server transmits all N requested files in C concatenated HTTP 
messages. As we can see, a significantly lower number of 
requests is being exchanged between the client and server, 
compared to using successive GET requests (Fig [^. Fig. 
depicts the same example, but with two connections, C = 2. 
When two connections are used, the two BURST requests 
are sent to retrieve the object files. Therefore, each BURST 
requests for two objects. 

A. Maximum Efficiency 

To compare with HTTP, the maximum efficiency using the 
BURST method is given by: 


C ■ (2 ■ (IP + TCP + HTTP) + ACK) + Li' 

Thus, the efficiency is clearly improved, as the TCP/IP 
overheads are counted maximally C times instead of N. Fig.|^ 
depicts the maximum efficiency with a fixed payload of 1400 
bytes. The efficiency is similar for both only when the number 
of objects corresponds to N <C. 


V. Experimental Results 

In this section, we experimentally demonstrate the potential 
of the proposed BURST method for HTTP. We made a proof- 
of-concept (POC), using HTTP GET requests. The source code 
we used is available onlin^ The scenario we investigate is as 
follows. We configured a virtual private server (VPS) with 
lighttpc0 which is a light and efficient HTTP server. The 
VPS has 1 GB random access memory (RAM), and does not 
experience any external requests except the ones received for 
this given experience. The experiment we consider consists of 
measuring the total request duration of retrieving an HTML 
document and its embedded objects. The HTML document 
contains a font of 44 KB, a CSS file of 120 KB, a javascript 
(jquery) file of 84 KB, and a variable number of images (N). 
Each request originates from a client located in Pittsburgh, PA, 
USA, and the VPS server is located in Dallas, Texas, USA. 

Fig. [T^ compares HTTP using GET requests and the 
proposed HTTP-Burst protocol, with C = {1,6}, which is 
the maximum allowed number of parallel connections. We 
vary the number of images, where the number of objects 
corresponds to the number of images, CSS, javascript, and font 
files. For each given number of images, we process the request 
10 times, and we record the mean and standard deviation. 
On Fig. we thus plot the mean and ± the standard 
deviation to illustrate the fluctuations. For each request, the 
total request duration is recorded, which corresponds to the 

^POC source code: https://github.coni/martinlevesque/http-burst 
^lighttpd: http://www.lighttpd.net/ 
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Fig. 10: Experimental measurements of the total request du¬ 
ration. 


time duration from the HTML request sending to the recep¬ 
tion of all retrieved objects. We observe that for HTTP, the 
request duration grows from 0.5 second to approximately 2.5 
seconds. With HTTP-Burst, however, similar request duration 
are experienced for low number of objects. For larger num¬ 
ber of objects (more than 30), HTTP-Burst outperforms the 
performance of the regular HTTP protocol. For instance, with 
HTTP-Burst and C = 6, even with 150 objects, the request 
duration is approximately as low as 1.2 seconds, compared 
to 2.5 seconds with HTTP GET requests. With HTTP-Burst 
and C = 1, the total request duration is worse compared with 
C = 6 for low number of objects. However, as the number of 
objects increases, HTTP-Burst with C = 1 still outperforms 
the regular HTTP protocol using GET requests. In terms of 
percentage improvement with the largest number of objects, 
150, and HTTP-Burst with C = 1 and C = 6, improvements of 
^ ~ ^2% are obtained, respectively. 
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VI. Conclusions 

In this paper, we first overviewed the HTTP traffic trends. 
The average webpage size and number of objects per webpage 
have continuously increased since 1995. In 2015, the average 
number of objects per webpage for desktops has reached 200 
objects. Even if objects can be retrieved with parallel TCP 
connections, the increasing number of objects causes signifi¬ 
cant overhead both from the network and server viewpoints. To 
overcome this issue, we proposed HTTP-Burst, which, instead 
of sending HTTP requests for all objects, retrieves webpage 
objects as bursts via the proposed BURST method, where ob¬ 
jects are grouped for improved efficiency. We experimentally 
investigated the proposed scheme by comparing it to using 
sucessive HTTP GET requests. The results shown a reduction 
of as much as 52 % of the total request duration under the 
considered configurations, thus illustrating the potential of the 
proposed protocol extension. In future work, we will look 
at the principal overhead causes and experiment the scheme 
under different conditions. 



















